IBIS Macromodel Task Group Meeting date: 14 October 2014 Members (asterisk for those attending): Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Ericsson: Anders Ekholm Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy eASIC Marc Kowalski SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Bob Ross (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad: We have some usual attendees traveling today. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Todd produce slides for co-optimization requirements discussion next week. - No report. - Arpad to review IBIS spec for min max issues. - In progress. ------------- New Discussion: BIRD 147.1: - Arpad: There where emails about this. - We may have reached a conclusion satisfying the question from SiSoft. - Todd: Walter and I have not reached that conclusion. - Todd summarized the question and exchange. - Todd: Two weeks ago Ambrish was back-pedaling a bit. - Last week Ken said "yes" to the idea that my example file would be approvable. - Arpad: It seemed from the emails that both answers were "yes". - Todd: Ken's response started off sounding like a "no". - Ambrish jumped in to clarify that it means "yes". - Cadence may be reluctance. - A more concise confirmation would help. - Radek: Do we need IBIS approval for private BCI files at all? - Todd: SiSoft has in the past been beaten for proposing things that seem proprietary. - We are sensitive to that and want assurance the files will be accepted. - Arpad: Do BCI files need tool vendor support? - If it's only a model maker issue compliance does not seem so important. - Walter: Protocols need to be tool-agnostic. - They are only between the TX writer and RX writer. - A standard "configurator" is important. - TXs tend to easily handle any protocol, with the right settings. - BIRD 147 was written when no RX was training and other vendor's TX. - We've learned more about link training since then. - Other features have been added as afterthoughts, and are not well thought out. - We are working with IC vendors to find a better solution. - Arpad: If we vote down BIRD 147 we have no other solution. - Walter: We should have more to say next week. - Todd: Walter has done much work and we are deciding whether to bring another BIRD forward. - Walter: We do need closure on this. - Arpad: Do we have progress on the co-optimization requirements slides AR? - Todd: No. - Arpad: Without an alternate we probably would vote yes for BIRD 147 - That might change if there is an alternate. - Radek: The issue of compatibility with existing TXs should be resolved. - We don't want 1000 BCI files either. - We should not vote until important questions are answered. - Walter: I am struggling with training stimulus patterns. - The standards are hard to read. - It might not work across vendors. - A Tektronix webinar calls for 3 obfuscation stages to create "rich" patterns. - BIRD 147 doesn't suggest that possibility. - We need IC vendors who are now writing software models to weight in. - I hope to have something shortly. BIRD 128: - Radek: Walter submitted this? - Walter: Ambrish and I did. - There has to be a well defined way to communicate to the TX in time domain. - I could add it to another BIRD and it would be less confusing. - Arpad: BIRD 128 was supposed to be independent. - Walter motioned to table BIRD 147. - Radek seconded. - There were no objections. - Walter motioned to table BIRD 128. - Radek seconded. - There were no objections. - Walter: The AR for me to get vendor package model input should be deleted. - Arpad deleted that. New Redriver Flow BIRD: - Walter: The downstream RX does not get the correct info to optimize itself. - Fangyi and I had an email discussion about this. - He needs to be part of the conversation. - We can't quantify how important it is. - Radek: We're not sure if the flow needs to be fixed or if the solution is adequate. - Walter: IC vendors agree on the flow we are using. - Any other flow would have to be justified. - Arpad: That should be avoided, for portability. Filter/Analog Driver: - Arpad: This is an enhanced C_comp idea. - Randy: There is some interest in getting back to this topic. - Walter: It goes back 2 to 6 years ago. - Michael Mirmak proposed a ladder network model. - We need something more complicated than just C_comp. - David: We have [External Model] waiting to be used. - Would that be better than "single use" approaches? - Walter: SPICE is limited to PWL. - Arpad: IBIS-ISS has sources that could construct an I-V curve. - Walter: It needs PWL controlled sources. - Final Stage Subckt was an arbitrary subckt proposal. - Arpad: [External Circuit] could be used. - But C_comp compensation inside buffers would be impacted. - If that could be solved it might work out. - John: We looked at that and rejected it. - It is not allowed to hook it into buffer circuit topology. - Walter: Arpad's point is well taken. - I-V curves are well defined. - But the V-T curves are defined without C_comp. - V-T curve quality matters. - Randy: VNA measurements of DDR4 gave a good model to 3GHz with simple RC. - Above that it's not as good. - A more complex model is needed. - Arpad: It would still use I-V curves. - Could it be RX only? - Randy: If the channel is not well terminated a more complex C_comp model is needed. - Arpad: This sounds like a need for DDR4. - Randy: There are a number of protocols that could us it. BIRD 157 Parameterize [Driver Schedule] - Arpad: Different models are needed for each frequency if [Driver Schedule] is used. - Not sure how much they are used. - They are basically a two tap SerDes. - Randy: [Driver Schedule] is not well supported across simulators. - There are implementation differences. - Walter: It was useful at 3GHz, but we don't see that any more. ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives